feat: add cryptoNetwork field to RealtimeFundingQuoteSource by kphurley7 · Pull Request #236 · lightsparkdev/grid-api

kphurley7 · 2026-02-27T20:08:38Z

Summary

Adds an optional cryptoNetwork field to RealtimeFundingQuoteSource.

Callers depositing stablecoins (USDC, USDT) via realtime funding need to specify which network they are depositing on so the server can generate a deposit address on the correct network. Without this field, the server has to hardcode the network (e.g. Solana devnet for sandbox), which won't work when production supports multiple networks.

The field is optional for backward compatibility — existing fiat realtime funding sources (USD, MXN, etc.) are unaffected.

Usage

{
  "source": {
    "sourceType": "REALTIME_FUNDING",
    "currency": "USDC",
    "cryptoNetwork": "SOLANA_MAINNET",
    "customerId": "Customer:..."
  }
}

Test plan

Confirm existing fiat realtime funding quote tests still pass (no cryptoNetwork required)
Confirm USDC realtime funding quote with cryptoNetwork: "SOLANA_MAINNET" returns a Solana deposit address
OpenAPI lint passes (make lint)

🤖 Generated with Claude Code

Callers depositing stablecoins (USDC, USDT) via realtime funding need to specify which network they are depositing on so the correct vault deposit address can be generated. Without this field, the server would have to guess or hardcode the network. cryptoNetwork is optional for backward compatibility — existing fiat realtime funding sources (USD, MXN, etc.) are unaffected. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

github-actions · 2026-02-27T20:09:11Z

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

openapi

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

python

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

typescript

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅

✅ grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅
pip install https://pkg.stainless.com/s/grid-python/e556863727aafbd29505af5006325d94de85647a/grid-0.0.1-py3-none-any.whl

✅ grid-kotlin studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

✅ grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅
npm install https://pkg.stainless.com/s/grid-typescript/09b91d5511100be716a7d2472558ece95178793b/dist.tar.gz

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-02-27 20:17:04 UTC

greptile-apps · 2026-02-27T20:12:07Z

Greptile Summary

Added optional cryptoNetwork field to RealtimeFundingQuoteSource schema to enable multi-network stablecoin deposits. This allows callers to specify which network (e.g., SOLANA_MAINNET, ETHEREUM_MAINNET) they'll deposit USDC/USDT on, enabling the server to generate deposit addresses on the correct network.

Backward compatible: Field is optional and only required for stablecoin currencies
Well documented: Clear description with example values in the schema
Correct workflow: Source schema edited in openapi/ directory, then make build run to update generated bundles
No issues found: Clean implementation following OpenAPI best practices

Confidence Score: 5/5

This PR is safe to merge with no issues identified
The change is a straightforward schema addition that maintains backward compatibility. The optional field is well-documented with clear examples, follows proper OpenAPI conventions, and solves a real need for multi-network stablecoin support. All three files were correctly updated following the project's workflow (source edit + make build).
No files require special attention

Important Files Changed

Filename	Overview
openapi/components/schemas/quotes/RealtimeFundingQuoteSource.yaml	Added optional `cryptoNetwork` field with clear documentation and examples for stablecoin network selection
openapi.yaml	Generated bundle correctly updated with new `cryptoNetwork` field from source schema
mintlify/openapi.yaml	Generated bundle correctly updated with new `cryptoNetwork` field for documentation

_{Last reviewed commit: a14bb9d}

pengying · 2026-02-27T20:46:56Z

openapi/components/schemas/quotes/RealtimeFundingQuoteSource.yaml

          for the full list of supported fiat and crypto currencies.
        example: USD
+      cryptoNetwork:
+        type: string


@wuvictor-95 I thought we were going to return an array of all supported networks in the quote response payment instructions?

It's what we are doing currently since we only have one network. In the future though, as we expand our capabilities to many networks, it makes less sense to do. We wouldn't want to create 3+ garbage deposit addresses for different networks everytime we create a quote

Oh man. This is another breaking change. And I thought address generation was cheap and we were going to use that pattern for other payment instructions.

This could be handled via config e.g. platform specifies which networks they care about when funding payments. Default is solana.

Yea, it's cheap but not 0. We have to check in each address to be watched on Alchemy, and alchemy has limits. It's definitely not scalable to, say, spin up 5 addresses for every payment. But perhaps we can manage that complexity and clean up all the addresses after 24 hours.

It's better to get breaking changes in now. I do think it's a better experience to be able to accept across multiple chains. As an example if I'm depositing to Uniswap, I generate the address once and can send to it from any network. Vs needing to specify the network prior to address generation.

It's not a breaking change if it's totally optional and we return all configured networks even when the currency is a stablecoin.

The description below makes it seem required when currency is any stablecoin

We should make a call here. IMO, we should just merge this and in the short term if it's empty we can return all available (we only support solana right now anyway). I want to unblock @kphurley7 to merge this.

yeah, based on victor's response I thought we were going to make this optional even for crypto currencies and return all available? That decision makes sense to me

Right now we are returning a list of payment instructions.

The PR description seems like this was auto-created since we're hardcoding to create a solana address in paycore. This is intended. We will hardcode networks in the backend since the original strategy was to just return a list of networks anyways.

I think we can close this PR. If we want to add CryptoNetwork as a optional field later on, we can. Not sure what work this is blocking though.

pengying reviewed Feb 27, 2026

View reviewed changes

kphurley7 requested a review from jklein24 February 28, 2026 02:38

jklein24 mentioned this pull request Feb 28, 2026

Add cryptoNetwork to realtimeFunding source object. #238

Closed

jklein24 approved these changes Mar 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add cryptoNetwork field to RealtimeFundingQuoteSource#236

feat: add cryptoNetwork field to RealtimeFundingQuoteSource#236
kphurley7 wants to merge 1 commit intomainfrom
kph/realtime-funding-crypto-network

kphurley7 commented Feb 27, 2026

Uh oh!

github-actions bot commented Feb 27, 2026 •

edited

Loading

Uh oh!

greptile-apps bot commented Feb 27, 2026

Important Files Changed

Uh oh!

pengying Feb 27, 2026 •

edited

Loading

Uh oh!

wuvictor-95 Feb 27, 2026

Uh oh!

pengying Feb 27, 2026

Uh oh!

wuvictor-95 Feb 27, 2026

Uh oh!

pengying Feb 27, 2026

Uh oh!

pengying Mar 1, 2026

Uh oh!

jklein24 Mar 3, 2026

Uh oh!

jklein24 Mar 3, 2026

Uh oh!

pengying Mar 3, 2026

Uh oh!

wuvictor-95 Mar 3, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

kphurley7 commented Feb 27, 2026

Summary

Usage

Test plan

Uh oh!

github-actions bot commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✱ Stainless preview builds

Uh oh!

greptile-apps bot commented Feb 27, 2026

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Uh oh!

pengying Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wuvictor-95 Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Feb 27, 2026 •

edited

Loading

pengying Feb 27, 2026 •

edited

Loading

wuvictor-95 Mar 3, 2026 •

edited

Loading